A Middleware Based on Chemical Computing for Service Execution The Current Problems and Solutions

Workflow Definition module defines the abstract workflow. This definition will be sent to the Workflow Instantiation component (introduced later on) for workflow instantiation process. As introduced, a service (or a functionality) can be delivered on difha l-0 07 94 02 3, v er si on 1 25 F eb 2 01 3 2 Middleware Architecture 7 ferent levels, so this abstract business process can publish multiple offers based on different global QoS constraints. For example, Offer1 permits to deliver the “Planning Trip” functionality within 10 seconds at the cost of 2 dollars; while Offer2 promises to deliver the same functionality within 5 seconds at the cost of 5 dollars. For each offer, the abstract workflow should be instantiated at least once (in lucky case that there is no error) to get the feasible execution plan. The “Offer Management” module manages all the possible execution plans for all the published offers. Once a feasible execution plan is found, the abstract business process can publish the relative offer in the Registry. In this way, this offer becomes discoverable by the other services during their instantiation process. Once its offer is selected, it has to wait to start the calculation until it receives the relative input. The Execution Engine is in charge of executing an execution plan. In our middleware system, the workflow execution is decentralized. The execution engine firstly cuts the execution plan to several blocks, and then sends these blocks to the relative partner services. On receiving these blocks, the partner services wait for their Another important module is “Monitoring”, which monitors and evaluates all the workflow executions. Once it detects the errors or deviations during the execution (for example, one of the partner service is crashed during the execution or the output format of a step does not conform with the input of its succeeding step), it will notify the Workflow Instantiation to adapt a part of execution plan. The adaptation is done in the run-time to avoid restarting the execution. From the client point of view, he can never perceive this action. In order to start the adaptation process, the whole execution plan will be sent to the Workflow Adaptation module. This module takes charge of replacing the bindings of a part of workflow in order that the following execution of workflow will still meeting the global QoS constraints. Take the example from Figure ??, during the Execution1 (this is the identity of the workflow execution), the monitoring detects that the second partner service (Euro Hotel) is crashed, so it informs the Workflow Adaptation module to carry our the adaptation process. The whole workflow should be delivered within 10 seconds at the cost of 2 dollars, where the Euro Hotel requires 3 seconds and 0.5 dollars and Car Renting costs 2 seconds and 0.5 dollars. Since the Euro Hotel service is crashed (due to some unpredictable reason such as server crash or network congestion), Workflow Adaptation module will consult the Registry to see whether it is possible to adapt a part of workflow in order to avoid the QoS violation. Finally, the Registry finds the service Cheap Hotel and Euro Car which requires 3.5 seconds 0.3 dollars and 1 seconds and 0.7 dollars. In this way, the two newly selected partner services cost only 4.5 seconds and 1 dollar which is better than the previous solution which costs 5 seconds and 1 dollar. In this sense, the rest of the workflow does not need to be adapted. ha l-0 07 94 02 3, v er si on 1 25 F eb 2 01 3 2 Middleware Architecture 8